The exploration fuzz harness `i64_lowering_doesnt_clobber_params` was
flagging `Movw R0, 0` writes as AAPCS param-clobber bugs when the very
next ARM op was a `Mov R0, _` overwriting the same register. The two-
instruction sequence appears in the function-final i32 return-value
placement — the selector zeros R0 and then immediately overwrites with
the actual return value. The Movw R0, 0 is a redundant dead store, not a
real clobber: the param is already preserved at this point and the
immediately-following Mov overrides the zero before any observer sees it.

This is the "option (b) harness-side" fix per the issue's investigation
comment — cheaper than the underlying peephole (option a, deferred for a
future codegen-quality PR) and lets the exploration harness make
forward progress toward gating-status promotion (#31).

## Carve-out shape

For each ARM instruction in the param-protection window, check whether
the immediately-following instruction also writes the same param reg.
If so, the current write is dead and gets skipped. Indexed iteration
keeps the lookup O(1).

## Soundness

The carve-out is local: it only suppresses writes whose result is
*provably* dead at the next instruction. A real mid-computation clobber
would either:
  (a) have non-overwriting next-op → still flagged.
  (b) be part of a chain where the *final* write overwrites R{p} →
      still flagged on the final write (its next op is typically Pop,
      which doesn't write the param reg).

So the carve-out does not hide real AAPCS clobbers; it only suppresses
the duplicate report on the first write of a write-then-overwrite pair.

## What this enables

After this lands and a couple of green fuzz-smoke cycles confirm the
harness stays quiet, it can be promoted from `gating: false` to
`gating: true` in `.github/workflows/fuzz-smoke.yml` — tracked as
task #31.

Issue: #112